<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE topic
  PUBLIC "-//OASIS//DTD DITA Composite//EN" "ditabase.dtd">
<topic id="topic1"><title id="ek156485">SET SESSION AUTHORIZATION</title><body><p id="sql_command_desc">Sets the session role identifier and the current role identifier of
the current session.</p><section id="section2"><title>Synopsis</title><codeblock id="sql_command_synopsis">SET [SESSION | LOCAL] SESSION AUTHORIZATION <varname>rolename</varname>

SET [SESSION | LOCAL] SESSION AUTHORIZATION DEFAULT

RESET SESSION AUTHORIZATION</codeblock></section><section id="section3"><title>Description</title><p>This command sets the session role identifier and the current role identifier
of the current SQL-session context to be <varname>rolename</varname>. The role name
may be written as either an identifier or a string literal. Using this
command, it is possible, for example, to temporarily become an unprivileged
user and later switch back to being a superuser. </p><p>The session role identifier is initially set to be the (possibly authenticated) role name
    provided by the client. The current role identifier is normally equal to the session user
    identifier, but may change temporarily in the context of <codeph>setuid</codeph> functions and
    similar mechanisms; it can also be changed by <codeph><xref href="SET_ROLE.xml#topic1"
      type="topic" format="dita"/></codeph>. The current user identifier is relevant for permission
    checking. </p><p>The session user identifier may be changed only if the initial session
user (the authenticated user) had the superuser privilege. Otherwise,
the command is accepted only if it specifies the authenticated user name.
</p><p>The <codeph>DEFAULT</codeph> and <codeph>RESET</codeph> forms reset
the session and current user identifiers to be the originally authenticated
user name. These forms may be run by any user.</p></section><section id="section4"><title>Parameters</title><parml><plentry><pt>SESSION</pt><pd>Specifies that the command takes effect for the current session.
This is the default.</pd></plentry><plentry><pt>LOCAL</pt><pd>Specifies that the command takes effect for only the current transaction.
After <codeph>COMMIT</codeph> or <codeph>ROLLBACK</codeph>, the session-level
setting takes effect again. Note that <codeph>SET LOCAL</codeph> will
appear to have no effect if it is run outside of a transaction.</pd></plentry><plentry><pt><varname>rolename</varname></pt><pd>The name of the role to assume.</pd></plentry><plentry><pt>NONE</pt><pt>RESET</pt><pd>Reset the session and current role identifiers to be that of the
role used to log in. </pd></plentry></parml></section><section id="section5"><title>Examples</title><codeblock>SELECT SESSION_USER, CURRENT_USER;
 session_user | current_user 
--------------+--------------
 peter        | peter

SET SESSION AUTHORIZATION 'paul';

SELECT SESSION_USER, CURRENT_USER;
 session_user | current_user 
--------------+--------------
 paul         | paul</codeblock></section><section id="section6"><title>Compatibility</title><p>The SQL standard allows some other expressions to appear in place of the literal <varname>rolename</varname>,
    but these options are not important in practice. Greenplum Database allows identifier syntax
     (<varname>rolename</varname>), which SQL does not. SQL does not allow this command during a transaction;
    Greenplum Database does not make this restriction. The <codeph>SESSION</codeph> and
     <codeph>LOCAL</codeph> modifiers are a Greenplum Database extension, as is the
     <codeph>RESET</codeph> syntax.</p></section><section id="section7"><title>See Also</title><p><codeph><xref href="SET_ROLE.xml#topic1" type="topic" format="dita"/></codeph></p></section></body></topic>
